Mobile computing devices, such as smartphones, are becoming more and more popular. As mobile devices become more and more popular, users of the devices demand more and more functionality from them. In some cases, users expect mobile devices to replace functionality once performed by desktop or laptop computing devices. This additional functionality can test the bounds of the hardware resources available on the mobile computing device, such as processor or display screen performance (e.g., resolution, refresh rate, or responsiveness). Generally, such hardware is not as powerful as that in desktop or laptop computers because of size, weight, and battery life issues.
Software for mobile devices frequently uses one of two approaches when rendering drawing objects on a display screen. These approaches generally access an application programming interface, such as OpenGL, for rendering drawing objects. The drawing application programming interface (API) for such systems is generally written in a native programming language, such as the C programming language. This can improve drawing performance on the mobile device over non-native programming languages and/or applications. In some cases, software code written to access the native drawing API is also written in the native programming language. The native software code sends drawing commands to the native drawing API to update drawing objects on the display screen of the mobile device. This native software code is generally specific to a particular type of mobile device, and separate native software code needs to be written, and/or compiled from the software code, for other mobile devices.
In other cases, software code can be written in a non-native programming language, such as a high-level, device-independent programming language (e.g., the Java programming language). The device-independent software code then accesses a wrapper for the native drawing API, such as the Java Native Interface (JNI). The wrapper can be written in the high-level, device-independent programming language. The wrapper generally includes an API that provides access to the features of the native drawing API. The device-independent software code then sends individual drawing commands to the wrapper API which are then passed to the native drawing API.